home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄26⁄90 / 0477-Persistent⁄virtual o-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  5.8 KB  |  122 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  LAI1         to D4384
  2.  
  3. Item    4741332                         20-Jan-90        08:28
  4.  
  5. From:   LAI1                            Lai, Edmund
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Persistent/virtual objects
  10.  
  11. I think Greg Colvin's persistent object solution is more a solution to "virtual
  12. object": the total size of all objects are too big to fit into memory and not
  13. all are needed to be in memory at the same time. So only a header of the object
  14. is keep in memory and the rest is load as needed. I think the Card sample
  15. program does more or less the same thing.
  16.  
  17. Other have pointed out some problems. Pointer to other object are not handled,
  18. it uses a lot of handles. Of course the object to lots of handle is that they
  19. still take up a lot of room. If you have a million objects and you calculate
  20. how much memory the dehydrated form alone would occupy, then scheme would not
  21. work. It works best when you have a small number of large objects (and there is
  22. no saving if there are many small objects).
  23.  
  24. The problem need to be distinguished from persistent object because if we have
  25. view objects, we can put it away on to disk and get it back later functionally
  26. intact, then I think we have solved the persistent object problem, but still we
  27. have not solve the problem that there is a very big view with so many subviews
  28. that they cannot be fitted into memory. That is the issue of virtual objects.
  29.  
  30. Larry Rosenstein's suggestion of using an index or ID to represent an object
  31. and load it on demand is a sound one and in fact is a better solution to the
  32. virtual object problem. Now suppose you have a million objects out there but
  33. there is still chance that the program will run in the 1M machine (how well
  34. that would run is another matter).
  35.  
  36. One way to distinguish the key and a object is to use odd longint to be the
  37. key. Since a handle is never odd, you can store object pointer and index in the
  38. same place, in the begining it is the index. Before you access the field you do
  39. the call
  40.  
  41. if Odd(longint(fOtherObject)) then
  42.  fOtherObject := KeyToObject(longint(fOtherObject));
  43. fOtherObject.DoItsThing;
  44.  
  45. This is not without its problem, if objects are virtual then they can be
  46. swapped out, so the fact it has been translated from index to handle is no
  47. guarantee.
  48.  
  49. One solution to the problem is have a reference count and not to swap out until
  50. the reference count is zero;
  51.  
  52. if Odd(longint(fOtherObject)) then
  53.  begin
  54.  fOtherObject := KeyToObject(longint(fOtherObject));
  55.  with fOtherObject do fRefCount := fRefCount + 1;
  56.  end;
  57. fOtherObject.DoItsThing;
  58.  
  59. TMyObject.Free;
  60.  begin
  61.  with fOtherObject do fRefCount := fRefCount - 1;
  62.  Inherited Free
  63.  end;
  64.  
  65. Or we can have a TList field fObjectsUsingMe so that when an object is purged,
  66. it would go through the list and reverting them to index, but there is a lot of
  67. bookkeeping to do.
  68.  
  69. There may be the question, why do this everytime fOtherObject is referenced,
  70. why not do it in object init time once. The problem is that if you a million
  71. objects connected in a link list, when you tried to init the first object you
  72. would bring in a million objects. With the approach advocated above, you would
  73. not bring in a object unless you really needs it. Of course it can be a mixture
  74. of both approachs, you know you are going to need to refer to the field many
  75. times, you do it at object init time, if it is a million object link list, you
  76. do it when you really need the other object.
  77.  
  78. Actually I think the cleanest approach is to always keep the index around, and
  79. translate to object when you use it, and there is a cache of recently used
  80. objects so that most of the time it is not necessary to go to the disk. So you
  81. have
  82.  
  83. KeyToObject(fOtherObjectKey).DoItsThing;
  84.  
  85. You may say that this is very inefficient. Obviously there are a lot more
  86. overhead compared to
  87.  
  88. fOtherObject.DoItsThing;
  89.  
  90. The question is that is this fast enough that the user would not care. I know
  91. at least one popular Mac program that use that approach and it does not seem to
  92. have a performance problem. I think people should try it out, if it is fast
  93. enough, why bother with other headaches.
  94.  
  95. Now on a complete different topic, I keep hearing that all this discussion is
  96. not a solution to persistent object problem becasue it does not address
  97. persistence of methods as well as data. If I have a view, I can save it and get
  98. it later, full functional, that is persistent object for me. The methods of the
  99. view is available to me before I save it and it is available to me when I load
  100. the object back in, why do I need to do anything about the methods. If what it
  101. means is that if I create a new method, there is no way of storing it for me.
  102. Well for MACAPP, you can not even create a new method on run time, so why blame
  103. it on persistence. If what you mean is that in OOP, objects is data +
  104. behaviour. Therefore if you just save data, transfer it to another environment
  105. then you cannot use it because there is no behavior(methods). If it is a view,
  106. you transfer the view object to another environment, they should have the
  107. methods for views and display it. So it is not a problem. If it is some kind of
  108. TMyObject, so that the class and hence methods are not available over there.
  109. Again MACAPP would not even allow you to create the object over there so it is
  110. not a problem.
  111.  
  112. Let us assume for a moment that all of these are indeed possible under MACAPP,
  113. then should we save methods as well as objects so that we can transfer behavior
  114. as well as data. Obviously that would be nice. But it would also be nice when I
  115. give you a MacWrite document, I give you a copy of MacWrite because without it
  116. you cannot read the document anyway, so data (documeent) is useless without
  117. behavior (application). While this is interesting in academic research, I am
  118. not sure how many developers want to support this. One day maybe object can
  119. have scripts attached to it like in HyperCard, but that is a completely
  120. different story.
  121.  
  122.